REMARKS 

Applicant is in receipt of the Office Action mailed May 17, 2007. Claims 1, 4, 5, 
6, 8, 9, 11, 18, 19, 20, and 21 have been amended. Claim 17 has been cancelled. Thus, 
claims 1-16, and 18-21 are pending in the case. Reconsideration of the present case is 
earnestly requested in light of the following remarks. 

Amendments 

Applicant has amended the independent claims to include the subject matter of 
claim 17, and most of the subject matter of claim 18. Applicant has also amended claims 
19 and 20 to make the subject matter of these claims statutory under section 101. 
Applicant believes that the claims as currently written are patentably distinct and non- 
obvious over the cited art, and are also statutory, and are thus allowable. 

Applicant has also amended the claims to replace the claim conjunction "and" 
with "or", per recent judicial interpretations of claim language. 

Section 101 Rejections 

Claim 21 was rejected under 35 U.S.C. 101 as being directed to non-statutory 
matter, specifically for being "drawn to a computer program per se". Applicant 
respectfully disagrees, and notes that claim 21 is directed to a method, and has been 
amended as indicated above to stipulate that the claimed method is computer- 
implemented. Moreover Applicant respectfully submits that the method of claim 21 as 
currently amended clearly performs multiple actions, and produces a tangible result, 
specifically, synchronization of a plurality of devices. 

In the Response to Arguments, the Office Action asserts that synchronizing 
multiple devices in a system is not itself a tangible result, and that the claim must indicate 
the particular type of system claimed to be statutory under section 101. Applicant 
respectfully disagrees, noting that there is no statutory requirement to specifically identify 
the particular application domain for an invention, and that the claimed systems and 
techniques for synchronizing multiple devices are themselves novel and useful, and 
produce a tangible result, specifically, a plurality of synchronized devices, which are 
useful in many different application domains. 
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Removal of the section 101 rejection of claim 21 is respectfully requested. 

Applicant further notes that claim 19, originally directed to an application 
programming interface (API), is now directed to a system that implements the API, and is 
thus statutory under section 101. 

Section 102 Rejections 

Claims 1 and 21 were rejected under 35 U.S.C. 102(e) as being anticipated by 
Conway et al. (USPUB 2004/0064750, "Conway"). Applicant respectfully disagrees. 

Amended Claim 1 recites: 

1. A memory medium that stores program instructions implementing an 
application programming interface (API) for synchronizing multiple devices in a system, 
wherein the API comprises: 

a plurality of functions invocable in a program to synchronize a plurality of 
devices, wherein each function is executable to perform a respective functionality related 
to synchronizing the plurality of devices, and wherein at least one of the plurality of 
functions is executable to access a plurality of instrument drivers corresponding 
respectively to the plurality of devices to synchronize the plurality of devices; 

wherein, in synchronizing the plurality of devices, the at least one of the plurality 
of functions is executable to: 

query each of the plurality of devices to determine a trigger clock signal 
for each of the plurality of devices based on one or more of: 
a common sample clock; 
a common reference clock; or 
a specified minimum trigger clock period; and 
synchronize the plurality of devices based on the determined trigger clock 
signals, wherein, in synchronizing the plurality of devices based on the determined 
trigger clock signals, the at least one of the plurality of functions is executable to: 

equalize phase of the common sample clock and/or the common 
reference clock of each of the plurality of devices; 
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equalize phase of the trigger clock signals of each of the plurality 

of devices; and 

condition driving and/or reception of triggers on trigger enable 
signals generated from the trigger clock of each of the plurality of devices. 

Nowhere does Conway disclose an application programming interface (API) 
for synchronizing multiple devices in a system, wherein the API comprises: a 
plurality of functions invocable in a program to synchronize a plurality of devices, 
wherein each function is executable to perform a respective functionality related to 
synchronizing the plurality of devices, and wherein at least one of the plurality of 
functions is executable to access a plurality of instrument drivers corresponding 
respectively to the plurality of devices to synchronize the plurality of devices, as 
recited in claim 1 . 

In asserting that Conway discloses these features of claim 1, the Office Action 

cites paragraphs [0007] - [0009] of Conway, which read thusly: 

[0007] The instrumentation hardware may be configured and controlled by 
software executing on the computer system. The software for configuring 
and controlling the instrumentation system typically includes driver 
software and the instrumentation application software, or the application. 
The driver software serves to interface the instrumentation hardware to the 
application and is typically supplied by the manufacturer of the 
instrumentation hardware or by a third party software vendor. The 
application is typically developed by the user of the instrumentation 
system and is tailored to the particular function that the user intends the 
instrumentation system to perform. The instrumentation hardware 
manufacturer or third party software vendor sometimes supplies 
application software for applications that are common, generic, or 
straightforward. 

[0008] Instrumentation driver software provides a high-level interface to 
the operations of the instrumentation device. The instrumentation driver 
software may operate to configure the instrumentation device for 
communication with the host system and to initialize hardware and 
software to a known state. The instrumentation driver software may also 
maintain a soft copy of the state of the instrument and initiated operations. 
Further, the instrumentation driver software communicates over the bus to 
move the device from state to state and to respond to device requests. 
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[0009] Some computerized instrumentation systems include several 
instrumentation and/or DAQ devices. Each device may generate and/or 
capture data based on a sample clock. For example, the sample clock on 
an arbitrary waveform generator may drive a DAC. Two or more devices 
may be considered to be digitally synchronized when their data capture 
and/or data generation circuits line up within a sample clock cycle. Digital 
synchronization may occur when the sample clocks of each device to be 
synchronized have substantially the same frequency (e.g., the devices' 
sample clocks may experience instantaneous frequency differences but, on 
average, the devices' sample clocks may not drift relative to each other). In 
addition, for digital synchronization, the devices to be synchronized are 
preferably able to respond to a trigger within the same sample clock 
period, and in the case of output devices, to output their data to a 
connector at substantially the same time. As described herein, two clocks 
are in phase when they are measured as having substantially the same 
frequency and substantially zero degrees of phase difference. 

As the above paragraphs make clear, in prior art approaches to device 
synchronization, application programs, e.g., written by the user, make calls to respective 
instrumentation drivers to interact with the respective devices, e.g., to coordinate 
synchronization among devices. Note that the application program must make individual 
calls to each respective instrument driver to interact with the respective device, and so to 
synchronize multiple devices, the application must make corresponding multiple (direct) 
calls to the respective instrument drivers of the devices. Thus, there are two software 
layers involved in synchronization of the devices — the application layer, and the driver 
layer. 

In direct contrast, the present application describes an API (comprising a plurality 
of functions) as an intermediate software layer interposed between the application layer 
and the driver layer, where, as claimed, the program (application) makes calls to the 
functions of the API, and these functions access the drivers. Moreover, as recited in the 
claim, at least one of the functions "is executable to access a plurality of instrument 
drivers corresponding respectively to the plurality of devices to synchronize the plurality 
of devices". In other words, rather than having to access each instrument driver 
individually via a respective function call as per the prior art, all of the instrument drivers 
of the plurality of devices are accessed via a single function call (the at least one of the 
functions) to synchronize the devices. Thus, the addition of this intervening layer (i.e., 
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the present API) significantly simplifies synchronization of multiple devices, which 
provides a great benefit over prior art approaches to multiple device synchronization. 

Nowhere does Conway, in the cited paragraphs or elsewhere, teach or suggest 
such an API, nor, more specifically, such an API function that is executable to access 
multiple instrument drivers to synchronize the plurality of devices. In fact, Conway 
makes no mention whatsoever of an API function that accesses a plurality of device 
drivers. 

Thus, for at least these reasons, Applicant submits that Conway fails to teach or 
suggest this feature of claim 1 . 

Nor does Conway disclose wherein, in synchronizing the plurality of devices, 
the at least one of the plurality of functions is executable to: query each of the 
plurality of devices to determine a trigger clock signal for each of the plurality of 
devices based on one or more of: a common sample clock; a common reference 
clock; or a specified minimum trigger clock period, as recited in claim 1. 

Cited paragraph [0016] reads: 

[0016] Various embodiments of a method and system for synchronizing 
trigger reception and generation on different instrumentation devices may 
involve each instrumentation device generating one or more trigger enable 
signals and delaying receipt (or driving) of a trigger signal until a 
transition (e.g., a rising or falling edge) in a trigger enable signal. In one 
embodiment, an instrumentation system may include several 
instrumentation devices and a communication medium (e.g., a bus) 
coupling the instrumentation devices. One of the instrumentation devices 
may process data in response to a sample clock signal. The sample clock 
signal may be generated by that instrumentation board from a reference 
clock signal. That instrumentation device may generate a trigger enable 
signal and delay performance of an operation in response to a trigger 
signal transmitted via the communication medium until a transition in the 
trigger enable signal. The trigger enable signal is not the sample clock 
signal. The trigger enable signal may be synchronized to another trigger 
enable signal generated by another one of the instrumentation devices. 

As may be seen, the cited text discloses, in Conway, each device generates trigger 
enable signals that may be synchronized with another device's trigger enable signal, and 
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each device delays performance of an operation until there is a transition in the trigger 
enable signal, where the trigger enable signal is not a sample clock signal for the device. 

Nowhere does the cited text (or Conway in general) describe an API function 
querying each of the plurality of devices to determine a trigger clock signal for each of 
the plurality of devices based on a common sample clock, a common reference clock, 
and/or a specified minimum trigger clock period. 

Thus, for at least these reasons, Applicant submits that Conway fails to teach or 
suggest this feature of claim 1 . 

Nor does Conway disclose synchronize the plurality of devices based on the 
determined trigger clock signals, wherein, in synchronizing the plurality of devices 
based on the determined trigger clock signals, the at least one of the plurality of 
functions is executable to: equalize phase of the common sample clock and/or the 
common reference clock of each of the plurality of devices; equalize phase of the 
trigger clock signals of each of the plurality of devices; and condition driving and/or 
reception of triggers on trigger enable signals generated from the trigger clock of 
each of the plurality of devices, as recited in claim 1. 

As discussed above, cited paragraph [0016] discloses that each device generates 
trigger enable signals that may be synchronized with another device's trigger enable 
signal, and each device delays performance of an operation until there is a transition in 
the trigger enable signal, where the trigger enable signal is not a sample clock signal for 
the device. 

Nowhere does the cited text (or Conway in general) describe synchronizing a 
plurality of devices based on the determined trigger clock signals by executing an API 
function to equalize phase of the common sample clock and/or the common reference 
clock of each of the plurality of devices, equalize phase of the trigger clock signals of 
each of the plurality of devices, and condition driving and/or reception of triggers on 
trigger enable signals generated from the trigger clock of each of the plurality of devices. 

Applicant notes that while paragraph [0041] of Conway discloses configuring 
clock generation circuits on devices "so that each device's sample clock is in phase with 
the sample clocks of the other devices", Conway makes no mention of an API function 
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that is executable to equalize phase of the common sample clock and/or the common 
reference clock of each of the plurality of devices, as well as equalize phase of the trigger 
clock signals of each of the plurality of devices, and condition driving and/or reception of 
triggers on trigger enable signals generated from the trigger clock of each of the plurality 
of device. 

For example, Applicant notes that paragraph [0058] discloses using "a device that 
can measure the phase difference between any two or more of the devices", e.g., "an 
external oscilloscope, a PXI digitizer (e.g., located in the same chassis as the devices 100 
whose TClk signals are being measured), or any other device or combination of devices 
that can perform such a measurement", and adjusting the phase of each TClk signal to 
synchronize the devices (with respect to TClk). Again, no mention is made of an API 
function executable to equalize phase of the common sample clock and/or the common 
reference clock of each of the plurality of devices, equalize phase of the trigger clock 
signals of each of the plurality of devices, and condition driving and/or reception of 
triggers on trigger enable signals generated from the trigger clock of each of the plurality 
of devices. In fact, paragraph [0064] discloses using dedicated digital circuitry in each 
instrument to perform such synchronization of the devices' TClk signals. Nowhere does 
Conway even mention equalizing phase of the trigger clock signals of each of the 
plurality of devices, nor conditioning driving and/or reception of triggers on trigger 
enable signals generated from the trigger clock of each of the plurality of devices. 

Thus, for at least these reasons, Applicant submits that Conway fails to teach or 
suggest these features of claim 1 . 

Thus, for at least the reasons provided above, Applicant submits that Conway fails 
to teach or suggest all the features and limitations of claim 1 , and so claim 1 and those 
claims dependent therefrom are patentably distinct and non-obvious over the cited art, 
and are thus allowable. 

Claims 19 and 21 include similar limitations as claim 1, and so the above 
arguments apply with equal force to these claims. Thus, for at least the reasons provided 
above, Applicant submits that claims 19 and 21, and those claims respectively dependent 
therefrom, are patentably distinct and non-obvious over the cited art, and are thus 
allowable. 
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Removal of the section 102 rejection of claims 1-21 is respectfully requested. 
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CONCLUSION 



In light of the foregoing amendments and remarks, Applicant submits the 
application is now in condition for allowance, and an early notice to that effect is 
requested. 

If any extensions of time (under 37 C.F.R. § 1.136) are necessary to prevent the 
above-referenced application(s) from becoming abandoned, Applicant(s) hereby petition 
for such extensions. The Commissioner is hereby authorized to charge any fees which 
may be required or credit any overpayment to Meyertons, Hood, Kivlin, Kowert & 
Goetzel P.C., Deposit Account No. 50-1505/51 50-82 100/JCH. 

Also filed herewith are the following items: 
1X1 Request for Continued Examination 
□ Other: 

Respectfully submitted, 

/Jeffrey C. Hood/ 

Jeffrey C. Hood, Reg. #35198 
ATTORNEY FOR APPLICANT(S) 

Meyertons, Hood, Kivlin, Kowert & Goetzel PC 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8800 

Date: 2007-08-16 JCH/MSW 
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